【linux】不小心对整个/usr/目录执行了chmod 777命令,如何恢复故障的权限设定 您所在的位置:网站首页 linux 命令行模式如何运行界面软件 【linux】不小心对整个/usr/目录执行了chmod 777命令,如何恢复故障的权限设定

【linux】不小心对整个/usr/目录执行了chmod 777命令,如何恢复故障的权限设定

2023-06-22 01:53| 来源: 网络整理| 查看: 265

一、问题背景

在安装ansys的时候,脑子抽风,以为/usr/目录是共享目录,直接把所有文件或目录的权限完全设置为全用户自由读写和执行即可。

但是没想到执行了命令sudo chmod -R 777 /usr/命令之后,出现了一大堆sudo权限错误。

较为典型的几个错误如下:

1、/usr/bin/sudo must be owned by uid 0 and have the setuid bit set 2、sudo: error in /etc/sudo.conf, line 0 while loading plugin “sudoers_policy”

在这里插入图片描述

在这里插入图片描述

二、如何进入恢复模式?

上面的错误表示 /usr/bin/sudo 文件的权限或所有者不正确。为了修复这个问题,需要将该文件的所有者更改为用户 ID 0(即 root 用户),并设置 setuid 位。

从恢复模式进入系统来解决这个问题。

首先用reboot命令重启系统。

在开机时,遇到主板相应的那个界面时,例如超微主板界面如下。如果你是Ubuntu系统,需要疯狂的按shift键。其他系统进入恢复模式的按键,你们可以去查查,一般来说就是esc或shift。 在这里插入图片描述 当 GRUB 引导加载程序出现时,选择 “Advanced options for Ubuntu”(或类似名称的选项)。 在这里插入图片描述 在“Advanced options”菜单中,选择带有 “(recovery mode)” 标签的最新内核版本。在这里插入图片描述

系统将进入恢复模式。

三、在恢复模式中执行以下命令

在恢复菜单中,选择 “root - Drop to root shell prompt” 选项。 在这里插入图片描述 以 root 用户身份进入命令行。执行以下命令:

chown root:root /usr/bin/sudo chmod 4755 /usr/bin/sudo pkexec chmod u+w,go-w /usr/libexec/sudo/sudoers.so

在这里插入图片描述 上图中有一个命令没执行,之后就出现了第一章问题背景中的第二个错误。所以三个命令一定都要执行到位。

最后,执行exit命令退出命令模式。

选择resume normal boot,这样就能回到正常桌面中。

在这里插入图片描述 这里回车确定。 在这里插入图片描述 如果你像我一样发现黑屏进不去,那么你可以用Ctrl+Alt+F2-6来进入TTY命令模式, 这样你就可以执行命令system ctl reboot -i来强制重启你的Linux系统。

这样重启之后,就能正常显示桌面了。

四、解决error日志文件不断生成的问题

参考:Ubuntu下error_log过大的终极解决方案

大概是因为仍然有些文件或目录的权限仍然不对,导致cups服务不断生成错误日志。足足占满了我的硬盘,我才发现!!! 在这里插入图片描述 在这里插入图片描述

4.1 修改dbus的权限

随后,执行下面几条命令即可解决。

sudo chmod 755 /usr/lib/cups/notifier/dbus # 修改 这个路径的权限 sudo chown root.root /usr/lib/cups/notifier/dbus # 修改 dbus文件的归属用户,如果是文件夹最好加-R sudo rm /var/log/cups/error* # 删除 error 文件 sudo /etc/init.d/cups restart # 重启服务 tail error_log # 查看 error 文件,如果返回空,说明成功了

这么设置之后,并没有解决。

4.2 谨慎修改/usr/bin文件夹的权限

于是我借鉴了解决ubuntu中的cups目录下的error_log日志沾满磁盘空间的问题的建议,直接将/usr/lib目录全部权限改为755。

执行命令sudo chmod 755 -R /usr/lib。

之后,我发现又开始出现那个【/usr/bin/sudo must be owned by uid 0 and have the setuid bit set】的错误了。

痛定思痛,我不得不深入探究这个错误到底是啥意思。

首先上面我在恢复模式中为啥要执行chmod 4755 /usr/bin/sudo,而不是chmod 755 /usr/bin/sudo呢,因为4位数的权限模式的最高位表示特殊权限。

最高位为 4,表示该文件具有 set user ID (SUID) 权限。SUID 使程序在执行时具有文件所有者的权限,而不是执行程序的用户的权限。在这种情况下,sudo 将以 root 用户权限运行,因为 /usr/bin/sudo 文件通常由 root 用户拥有。

而在命令chmod 755 /usr/bin/sudo中,没有特殊权限,因此 sudo 将以执行程序的用户权限运行。

使用chmod 4755 时,sudo 将以 root 用户权限运行,而使用 chmod 755 时,sudo 将以执行程序的用户权限运行。通常,为了使 sudo 正常工作,需要设置 SUID 权限,因此一定要使用chmod 4755。

所以我又得去恢复模式执行一遍chmod 4755 /usr/bin/sudo。

4.3 对/var/文件夹的权限做一个默认设置

因为上面两个步骤还没解决问题,所以不得不再继续尝试!

经过博主JensLee的开导——error_log塞满了70+G的错误日志。Notifier for subscription 94 (dbus://) went away, retrying!,我又执行命令sudo chmod 755 -R /var/,来修改目录/var/的权限为默认。当然,在修改权限前,还是要删除一下文件和重启CUPS服务的。

4.4 试试删除cups里的所有文件

我上面三步都做了,还是没解决。

这次我怀疑是不是那个/var/log/cups/里的access*(以access开头的几个file)文件的问题,可能命令sudo chmod 755 -R /var/只能修改目录的权限,不能修改文件的权限吧。

于是乎我将这个cups的error文件全删了的同时,也把那几个access文件也删了,自然用的是sudo rm -rf xxx命令。

目前好像真的解决了,已经几个小时了还是没有蹦出来那个错误日志

Ref

CSDC博主“”上海一亩地“”写的文章【Linux系统目录下文件权限、所有者全部恢复】中,提到用相近机器的权限文件去恢复权限设定。

可能他的意思是我用上面的三条命令,还是没办法恢复至初始设定。

不过大家可以尝试一下下面两条命令(我没试过,这是AGI生成的,有效性存疑,谨慎尝试哦),第一条是给所有目录设置默认权限,第二条的修改对象是文件:

sudo find /usr/ -type d -exec chmod 755 {} \; sudo find /usr/ -type f -exec chmod 644 {} \;

既可以在恢复模式中执行,也可以在执行上面三条命令之后,进入正常模式的终端中执行。

如此执行之后,特定的目录或文件,可能需要特定的权限,你们根据自己需要进行自定义修改。



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有